REMARKS 

In the Office Action dated March 20, 2008, claims 1-8 were rejected under 35 
U.S.C. §112, first paragraph as failing to comply with the written description 
requirement, because the Examiner stated the present specification does not provide 
support for the language in claim 1 stating that a computerized operation model that 
mimics a reproducible operation that occurs during a normal usage time, is 
generated during the normal usage time. 

In response, independent claim 1 has been amended to delete the reference 
to "normal usage time" and to instead describe the model as being generated during 
interaction between the technical system and at least one patient of the medical 
facility. Since the Examiner did not object to the subsequent language in claim 1 
referring to operation of the technical system according to the aforementioned 
operation model while using a newly-installed software system, during a non-normal 
usage time of non-interaction with patients of the medical facility, Applicant assumes 
the Examiner does not have any objection to the use of the term "non-normal usage 
time" in that context. Applicant is satisfied that the relevant distinction exists in the 
language of claim 1 between the generation of data during a time when the technical 
system is interacting with at least one patient of the medical facility, and the testing 
of newly-installed software, using the generated operation model, at times when the 
technical system is not interacting with patients of the medical facility. Applicant 
believes it is inherent that the interaction of the technical system with at least one 
patient of the medical facility will occur during a normal usage time of the medical 
facility, and therefore it is not necessary to explicitly include that language in the 
language of claim 1. 
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Claim 1 is therefore submitted to be in full compliance with all provisions of 
§112, first paragraph. 

Claims 2, 4 and 5 were rejected under §112, second paragraph as being 
indefinite. Editorial changes have been made in those claims, which Applicant 
submits are sufficient to overcome this rejection. Additionally, an error in the 
dependency of claim 4 has been corrected. 

Claims 2, 4 and 5 are therefore submitted for this further reason to be in full 
compliance with all provisions of §112, second paragraph. 

Claims 1, 2 and 4-8 were rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Pope et al. in view of Hameluck et al. and Havens et al. This 
rejection is respectfully traversed for the following reasons. 

The Pope et al. reference discloses an automated software testing system 
that is used to test "resident" (i.e., existing) software at a computer work station or in 
personal computers, as stated in the Abstract and at column 2, lines 55-57. For this 
purpose, mouse activities and keystrokes are recorded during execution of a first 
version of interactive software, and selected display images are captured. The 
recorded mouse activities and keystrokes are played back with a second version of 
the interactive software, and display images are again captured. The captured 
images generated with the second version of the interactive software are compared 
with the generated images from the first version. 

As best understood by the present Applicant, the Examiner appears to be 
equating interaction of the user of the interactive software as disclosed in Pope et al., 
with the interaction of the technical system with the patient as set forth in 
independent claim 1 of the present application. Applicants respectfully submit this is 
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not an accurate comparison or equation, and is not an equivalency for comparable 
types of operation that would be considered to be applicable or appropriate by a 
person of ordinary skill in the field of testing of medical software. 

The testing of the software of the type described in the Pope et al. reference 
is for determining compatibility of the software with the operator of the software itself. 
In the context of a medical imaging facility, for example, this would be comparable to 
testing the operating software for an imaging device by actions implemented by a 
medical/technical assistant, i.e., the person who will actually operate the imaging 
system to obtain image data from a patient. Other than possibly being instructed in a 
routine manner during the medical image data acquisition procedure (such as by 
being told to "lie still" or to initiate a breath-hold), the patient from whom medical 
image data are being acquired is basically a passive participant in the procedure. 
The patient interacts with the medical imaging facility by means of the imaging 
radiation or magnetic fields or ultrasound that is generated by the technical facility, 
but the patient himself or herself is not the person who is actually testing the 
software. 

If the Examiner believes there is no distinction, or at least not a patentable 
distinction, between the type of active user-interaction described in the Pope et al. 
reference, and the type of passive patient interaction disclosed and claimed in the 
present application, the Examiner is invited to be an examination subject in an 
imaging system while the medical/technical assistant is undergoing the user- 
interactive type of software testing that is described in the Pope et al. reference. 
Applicant submits the Examiner (or any other examination subject in such a 
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situation) would, at a minimum, experience significant discomfort, and may even be 
placed at the risk of being injured. 

In fact, it is this possibility of risking injury to a patient that forms the basis of 
the type of testing disclosed and claimed in the present application. In accordance 
with the subject matter of claim 1, an operation model is generated during interaction 
between the technical facility and a patient using the existing software of the system. 
Presumably, the existing software is operable in a manner that is known to be safe 
and that does not pose a risk of injury to the patient. In the case of yet-to-be- 
installed new software, it is not positively known whether the new software can be 
operated without presenting a risk to the patient, and therefore in accordance with 
the present invention the same technical facility that was previously operated with 
the existing software is subsequently operated, without any interaction with a patient, 
in order to test the new software, by operating the system using the operation model 
that was generated while a patient was present. Therefore, the new software can be 
tested in a safe manner that poses no risk of injury to a patient. 

For these reasons, the user-interactive testing procedure disclosed in the 
Pope et al. reference would be completely unsuitable for testing new software in a 
medical system, at least if the testing of the software is intended to include, at some 
point, interaction of the medical facility with a patient. A person of ordinary skill in the 
field of testing new software for operating medical systems would immediately 
realize that the procedure and system disclosed in the Pope et al. reference would 
be not only unsuitable for that purpose, but could not be used without risking liability 
on the part of the medical facility (hospital or clinic) in which the technical system is 
located. 
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The Examiner has acknowledged that the Pope et al. reference does not 
specifically disclose generating an operation model during a "normal" usage time on 
customer premises, and has relied on the Hameluck et al. reference for that purpose. 
Applicant will address the teachings of the Hameluck et al. reference below, but for 
the above reasons Applicant submits that for the testing of interaction between the 
user of software as disclosed in Pope et al., there is no reason whatsoever to even 
take into account the generation of an operational model during a "normal" usage 
time of the system disclosed in Pope et al. 

As to the Hameluck et al. disclosure itself, that reference describes a buffered, 
screen-capturing software tool for testing the use of particular computer applications. 
In the discussion relating to the background of the invention disclosed in the 
Hameluck et al. reference, testing methods are described such as field testing, 
wherein a trained usability tester is deployed at a customer site in order to observe 
users doing real work in making use of a computer system. In this context, the 
Hameluck et al. reference also discloses beta testing, wherein an early version of the 
software product is made available to a number of beta evaluation participants. 
These types of field testing are described at column 1, lines 39-49 and column 1, line 
66 through column 2, line 2 in the Hameluck et al. reference. As described therein, 
these types of field testing techniques require a large amount of labor and resources 
and time, and in the case of beta testing, the difficulty of accurate reporting is a 
further disadvantage. The method and apparatus disclosed in the Hameluck et al. 
reference are for the purpose of overcoming these specific problems by leading a 
user through a test to be performed when the user encounters an aspect of the 
software that the user does not consider acceptable, or if some other problem is 
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encountered. This is described at column 5, lines 12-17 and is shown in Figures 1 
and 3-6 and the corresponding description in the Hameluck et al. reference. 

Therefore, just as in the Pope et al. reference, the Hameluck et al. reference 
teaches evaluating the test in question by recording screen activity (as described at 
column 5, lines 7-11). Moreover, the user in the Hameluck et al. reference works 
with the new software, at least for beta testing, and records any flaws that are 
encountered, as described at column 5, lines 12-23. Just as in the Pope et al. 
reference, therefore, implementing the Hameluck et al. procedure at any time 
wherein a patient is exposed to the technical facility in which the software is running 
would expose the patient to unacceptable risks. 

The Havens et al. reference discloses passive shielding of a mobile magnetic 
resonance imaging magnet, and as far as Applicant can determine, the Havens et al. 
reference is not concerned with any type of testing of such a magnet. Although the 
Havens et al. reference describes the fact that the mobile MRI device can be used in 
parking lots adjacent to a hospital or medical facility (column 1, lines 28-29), there is 
no disclosure in the Havens et al. reference as to any type of testing of such a 
device, nor the software that operates such a device. 

Applicant therefore respectfully submits that there is no teaching, motivation 
or suggestion in any of these references to combine the references in the manner 
proposed by the Examiner, and more importantly, even if such a combination were 
made, Applicant submits, for the above reasons, that the subject matter of 
independent claim 1 still would not result. Claim 1, therefore, would not have been 
obvious to a person of ordinary skill in the field of testing software for operating a 
medical system that interacts with a patient, under the provisions of 35 U.S.C. 



-10- 



§1 03(a), based on the teachings of Pope et al., Hameluck et al. and Havens et al. 
Claims 2 and 4-8 add further limitations to the non-obvious subject matter of claim 1 , 
and therefore none of those claims would have been obvious to a person of ordinary 
skill in the field of testing software for use in patient-interacting medical equipment, 
for the same reasons discussed above in connection with claim 1. 

Claim 3 was rejected under 35 U.S.C. §1 03(a) as being unpatentable over 
Pope et al., Hameluck et al. and Havens et al., further in view of Barfield et al. The 
above arguments with regard to claim 1, from which claim 3 depends, are equally 
applicable to this rejection of claim 3. Even if the Pope et al./ Hameluck et al./ 
Havens et al. combination were further modified in accordance with the teachings of 
Barfield et al., Applicant submits, for the above reasons, that the subject matter of 
claim 3 still would not result. 

All claims of the application are therefore submitted to be in condition for 
allowance, and early reconsideration of the application is respectfully requested. 

The Commissioner is hereby authorized to charge any additional fees which 
may be required, or to credit any overpayment to account No. 501519. 
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